JSAI2026 Lost in the Files: 複数専門文書からの網羅的情報抽出における長コンテキストLLMとRAGの比較
テーマ
見落としが許されない
生成回答の自然さではなく、必要な要素をどれだけ網羅できるかに注目する
これもまたRetrieverに注目する研究方針だ。王道なのかもしれない daiiz.icon 背景課題
実務では、似た構造の文書を横断して確認する場面が多い
年度別資料・報告書・契約書など
RAGは関連箇所を絞り込めるが、検索漏れやチャンク境界による情報欠落が起きる Long context LLMは全文を読めるが、文書数が増えると混同や見落としが起きる可能性がある
ファイル単位でも同様のことが起きると報告されている（NLP2026）
実験設定
総ページ数は160ページに固定し、文書数が増えたときの影響を見る
評価: 正解要素をどれだけ拾えたかという再現率で行う
年度まで正しく対応できているかも評価する
RAGはページ単位でチャンク化
タスク分類
Type A：局所・定型検索型
情報が特定ページや表にまとまっている（抽出問題）
例：役員名、設備投資額、社債情報など
Type B：広域・連続記述型
情報が章全体に連続して書かれている（広域な抽出問題）
例：研究開発活動、リスク項目の一覧など
Type C：条件・トピック絞り込み型
広い候補の中から条件に合うものだけを抽出する（抽出＋判定問題）
例：AI関連、脱炭素関連、大学連携など
結果
Type A: RAGが強い
見出しや表題で検索しやすく、年度メタデータも効く
局所的な情報を正確に拾う用途に向いている
コスト効率も良い
Type B: Long context LLMが強い
章全体を順番に読む必要があるため、全文入力のほうが安定する
RAGは章の冒頭ページに検索が偏り、後半の具体的記述を落としやすい
Type C: 両方とも難しい
条件判定と網羅的抽出を同時に行う必要がある
文書数が増えると、RAGは検索ノイズ、全文入力は年度混同が目立つ
商用検索システムを開発運用している身としても、感覚と一致する結果だ daiiz.icon
考察
RAGの構造的な限界
タイトル（見出し）ページに引っ張られがち
見出しを後続ページにつけ回すなどの探索戦略の再設計が必要
全文入力の脆弱性
判定負荷と年代混同
限界点は、入力長というよりも処理の負荷の合計にある
感想 daiiz.icon
やっぱり質問の難易度に応じて動的に戦略を切り替えていくしかないのかな
適切なTypeにルーティングする役目の存在が必要になる（クエリバランサー？）